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INTRODUCTION 


The  purpose  of  this  project  was  to  design  an  experimental  paradigm  to  study  collaboration 
in  multidisciplinary  design  teams.  According  to  Bulkeley  (1993),  the  number  of  organizations 
using  the  multidisciplinary  design  team  approach  is  increasing.  For  most  designers,  the  major 
drawbacks  of  multidisciplinary  design  teams  revolve  around  communications  with  other  team 
members  (Bulkeley,  1993).  Designers  feel  that  too  much  time  must  be  devoted  to  design  team 
meetings.  Preparation  for  meetings  and  the  actual  time  spent  in  these  meetings  reduces  the  amount 
of  time  designers  have  to  work  on  the  design  itself.  Simply  scheduling  meetings  may  be  time 
consuming.  If  team  members  are  not  located  in  close  proximity  (i.e.,  in  the  same  building,  city, 
state,  etc.),  travel  time  needs  to  be  factored  in.  In  addition,  understanding  and  keeping  track  of 
input  from  all  team  members  can  be  overwhelming. 

To  alleviate  some  of  these  problems,  computer  and  information  technologies  are  being  used 
more  and  more  for  communication  and  team  decision  support.  Bulkeley  (1993)  noted  that 
designers  rated  computer  tools  that  supported  design  and  communication  among  their  most 
important  design  tools.  These  tools  include  such  things  as  group  decision  support  systems, 
groupware  products,  electronic  mail  (email),  computer  conferencing,  design  rationale  databases, 
etc.  The  impact  these  technologies  have  on  the  process  of  design  team  collaboration  and  decision 
making  are  still  relatively  unknown.  Furthermore,  because  many  of  these  technologies  are  still 
being  developed,  we  felt  that  research  on  design  team  collaboration  could  potentially  inform  their 
development.  As  an  initial  first  step  in  a  program  of  research  focused  on  computer  support  for  team 
design,  we  developed  an  experimental  paradigm  to  study  the  process  of  collaboration  in  design 
teams.  The  focus  of  this  paper  is  on  the  development  of  this  paradigm. 

This  paper  begins  by  describing  the  background  and  gives  an  historical  overview  of 
multidisciplinary  design.  Critical  issues  for  effective  collaboration  are  highlighted.  Next,  the  steps 
taken  to  develop  an  experimental  task  for  multidisciplinary  design  teams  are  described.  Included  is 
a  discussion  of  the  selection  of  a  design  problem  and  the  elicitation  of  knowledge  from  design 
experts.  The  paradigm  and  its  rationde  are  then  described.  Finally,  the  potential  uses  for  the 
paradigm  are  discussed. 

BACKGROUND  AND  HISTORICAL  OVERVIEW 

Redesigns  and  long  product  life  cycles  can  be  very  costly  in  product  design.  According  to 
Kochan  (1991),  United  States  and  European  designers  spend,  on  average,  50%  of  their  time  in 
redesign  activities.  In  contrast,  their  Japanese  counterparts  spend  only  10%  of  their  time  on 
redesign.  Similarly,  the  typical  product  development  lead  time  in  Europe  is  63  months,  as 
compared  to  43  months  in  Japan.  Multidisciplinary  design  (also  known  as  concurrent  engineering) 
has  been  suggested  as  a  way  to  get  products  to  market  quicker  with  fewer  costly  redesigns 
(Kochan,  1991;  Sobieski,  1990). 

This  approach  involves  designers  from  various  specialties  (e.g.,  industrial  engineering, 
mechanical  engineering,  human  factors,  production  manufacturing)  working  together  to  integrate 
knowledge  early  in  the  design  process.  Concurrent  engineering  shortens  the  product  life  cycle 
(i.e.,  the  time  it  takes  for  product  development  from  inception  to  market)  because  tasks  can  be  done 
simultaneously.  Fewer  redesigns  are  necessary  because  designs  are  scrutinized  from  multiple 
viewpoints  prior  to  fixing  or  constraining  the  design. 

In  contrast,  more  traditional  approaches  generally  involve  design  tasks  being  completed 
sequentially  and  independently.  Kochan  (1991)  refers  to  this  as  "over-the-fence"  engineering. 

Once  a  group  of  designers  from  a  particular  discipline  completes  their  contribution  to  the  design. 
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they  pass  it  on  to  the  next  department  or  group  of  designers.  By  designing  sequentially,  the 
problem  is  viewed  from  a  single,  narrow  perspective  at  each  step  of  the  way.  Designers  who  are 
involved  early  have  greater  control  over  the  final  outcome.  Designers  who  get  involved  later  simply 
fulfill  a  design  evaluation  role.  They  are  limited  to  making  recommendations  for  design  changes. 

Unfortunately,  at  this  point,  there  may  be  a  reluctance  to  make  the  recommended 
modifications  or  changes.  Redesigning  may  be  costly.  Furthermore,  the  goals  of  designers  in  the 
early  stages  may  be  categorically  different  from  those  involved  in  later  stages.  Early  on  the  goal 
may  be  to  design  something  that  works.  Later  in  the  process  the  goal  may  become  one  of  designing 
something  that  can  be  manufactured  cheaply  and  efficiently,  as  well  as  somediing  that  will  be  user 
friendly.  Often  times  these  goals  are  incompatible.  In  addition,  when  components  are  designed 
independently,  the  parts  may  not  be  integrated  easily. 

The  concurrent  engineering  approach  is  believed  to  be  an  improvement  over  traditional 
approaches  because  it:  shortens  product  development  cycles,  results  in  designs  that  are  simpler  and 
cheaper  to  manufacture,  results  in  better  designs,  improves  quality  and  reliability,  produces 
products  that  match  customer's  needs  more  precisely,  results  in  better  cost  controls,  helps  the 
organization  be  more  competitive,  and  reduces  the  need  for  changes  late  in  the  design  process 
(Bulkeley,  1993;  Kochan,  1991). 

Collaboration  in  Multidisciplinary  Design 

As  the  popularity  of  the  concurrent  engineering  approach  and  multidisciplinary  design 
grows,  the  need  for  better  understanding  of  collaboration  among  design  team  members  is  needed. 
According  to  Gray  (1989),  collaboration  involves  interdependent  stakeholders  with  different 
perspectives  who  have  joint  ownership  and  collective  responsibility  for  decisions  and  who  must 
work  together  constructively  to  arrive  at  solutions. 

Because  multidisciplinary  design  involves  collaboration  among  a  variety  of  team  members, 
it  may  be  best  understood  as  situated  problem  solving.  This  perspective  posits  that  problem  solving 
takes  place  within  a  particular  context  (i.e.,  the  situated  context)  and  that  this  context  shapes  how 
the  problem  is  approached  and  solved.  A  situated  context  is  one  that  involves  social 
interdependence  between  actors  who  share  responsibility  for  solving  the  problem.  Through  social 
interaction,  the  individuals  construct  a  joint  understanding  of  the  problem,  develop  shared  values 
and  norms,  and  become  involved  in  a  reciprocal  exchange  of  knowledge  (Lave,  1991).  In  this 
sense,  the  situated  context  is  not  static,  but  always  evolving  and  changing  as  the  problem  and  its 
solution  unfold. 

According  to  Young  and  McNeese  (in  press),  there  are  10  factors  that  characterize  situated 
problem  solving.  First,  solving  the  problem  must  require  the  use  of  multiple  cognitive  processes 
and  multiple  paths  to  the  solution.  Second,  the  context  in  which  the  problem  occurs  is  complex  and 
provides  a  wide  array  of  perceptual  cues  that  inform  those  involved  about  the  possibilities  that  the 
situation  affords.  Third,  solving  the  problem  involves  identifying  attributes  of  the  problem  and 
separating  the  irrelevant  from  the  relevant  information.  Fourth,  several  competing  solutions  can  be 
generated  for  the  problem.  Fifth,  given  the  uncertainty  involved  in  solving  the  problem  and  its  ill- 
structured  nature,  the  problem  is  best  approached  by  generating  sub-problems.  Sixth,  the  context  is 
interpersonal  and  involves  social  interaction.  This  social  interaction  defines  the  roles  of  the  actors 
and  the  meaning  of  their  actions.  Seventh,  as  the  group  works  out  the  problem,  they  build  a  shared 
perception  or  understanding  of  the  problem  and  its  potential  solutions.  Eighth,  situated  problem 
solving  involves  the  integration  of  distributed  knowledge.  Distributed  knowledge  means  that  each 
individual  brings  to  the  situation  unique  information  based  on  past  experiences  and  learning 
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opportunities.  Across  the  group,  this  information  may  reflect  a  variety  of  domains  and  specialties. 
The  group  must  then  share  and  integrate  each  member's  unique  information.  Ninth,  as  the  problem 
unfolds,  the  group  establishes  a  pattern  of  interaction.  This  pattern  or  developmental  history 
becomes  part  of  the  context  and  heavily  influences  later  interactions  and  decisions.  Finally,  in 
situated  problem  solving,  the  context  involves  values,  intentions,  and  goals  that  have  personal  and 
social  significance.  Thus,  the  situated  context  has  important  implications  for  individuals’  identities. 

Multidisciplinary  design  is  similar  to  situated  problem  solving  because  it  can  be 
characterized  as  "a  goal  oriented,  constrained,  decision-making  exploration,  and  learning  activity 
that  operates  within  a  context  that  depends  on  the  designer's  perception  of  the  context"  (Gero, 

1990,  p.  28).  The  design  develops  through  the  social  interaction  of  the  team  members.  Because 
they  come  from  a  variety  of  disciplines,  faiowledge  is  distributed  across  team  members.  Members 
of  the  team  work  on  the  design  task  relying  on  their  own  unique  information  and  other  team 
members  to  educate  them. 

Critical  Issues  in  Collaboration 

Unfortunately,  multidisciplinary  design  teams  do  not  effectively  share  distributed 
knowledge.  Research  on  group  decision  making  (Stasser,  1992;  Stasser  &  Titus,  1985;  1987)  has 
shown  that  groups  tend  to  focus  their  discussion  on  commonly  shared  information  and  neglect  to 
discuss  unique  or  unshared  information.  This  results  in  groups  arriving  at  incorrect  or  faulty 
decisions.  Because  only  one  member  of  the  team  knows  a  particular  piece  of  information,  it  has  a 
lower  probability  of  being  brought  up  in  group  discussions. 

Team  members  may  also  have  difficulty  sharing  information  because  they  do  not  share  a 
common  framework.  Often  individuals  from  different  disciplines  misunderstand  and  misinterpret 
what  each  other  says.  Because  of  differences  in  their  backgrounds  and  training,  they  speak 
different  languages  (Boff,  1987).  Each  discipline  has  its  own  jargon,  metaphors,  acronyms, 
definitions  for  words,  labels  etc.  (Bucciarelli,  1988).  In  some  instances,  the  same  label  may  be 
used  to  explain  exact  opposite  things  (Fotta  &  Daley,  in  press).  Without  a  common  framework,  the 
advantages  of  the  multidisciplinary  team  approach  cannot  be  realized. 

Although  a  multidisciplinary  team  may  share  a  common  goal,  team  members  may  identify 
more  strongly  with  their  own  discipline  than  with  the  team  as  a  whole.  Bucciarelli  (1988,  p.  168) 
observed  that  "decisions  made  across  disciplines  are  best  seen  as  negotiations  among  parties  who, 
while  sharing  a  common  goal  at  some  level,  hold  different  interests."  If  communication  is  difficult, 
both  a  shared  perception  and  a  shared  identity  may  be  more  difficult  to  build. 

Furthermore,  designers  draw  heavily  on  their  previous  design  experience.  So  instead  of 
generating  and  carefully  evaluating  all  possible  design  alternatives,  designers  rely  on  a  case-based 
design  strategy  (Gero,  1990;  Klein,  1987).  In  case-based  design,  designers  draw  analogies 
between  their  present  design  and  previous  ones.  Case-based  designs  are  efficient  because  features 
of  a  previous  design  can  be  incorporated  into  the  new  design  project.  Unfortunately,  unnecessary 
components  of  the  original  design  may  also  get  incorporated.  Because  these  features  are  spuriously 
associated  with  essential  ones,  they  needlessly  restrict  the  design  options  considered.  Designers 
may  have  trouble  differentiating  and  articulating  which  features  are  essential  and  which  are  not. 

The  result  may  be  misanalogies.  Misanalogies  occur  when  previous  learning  is  applied  to  a 
situation  where  it  may  be  inappropriate  or  conflict  with  other  aspects  of  the  design.  Because 
misanalogies  are  difficult  to  articulate,  they  add  to  the  communication  problems  multidisciplinary 
design  teams  face. 
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Coordinating  communication  may  be  difficult  for  multidisciplinary  design  team  members 
because  they  may  work  on  different  schedules  or  may  be  separated  by  physical  distances.  For 
example,  anyone  who  has  played  telephone  tag,  understands  the  frustration  that  can  result  from 
being  unable  to  communicate  with  another  team  member.  Add  to  this  time  constraints  and  you  have 
a  potentially  volatile  situation.  The  result  may  be  that  team  members  fail  to  communicate  with  one 
another  and  base  decisions  on  incomplete  or  inaccurate  information. 

As  noted  earlier,  organizations  are  using  multidisciplinary  design  teams  to  develop  high 
quality  new  products,  quickly  and  efficiently.  Effective  collaboration  is  important  to  successfully 
implement  this  approach.  Thus,  understanding  the  nature  of  the  collaboration  process  and  how 
computer  tools  (e.g.,  groupware,  email)  can  aid  collaboration  is  necessary.  We  focused  our 
attention  on  developing  an  experimental  paradigm  because  of  the  difficulty  in  assessing  the 
effectiveness  of  design  decisions  and  errors  in  a  naturalistic  environment.  Furthermore,  we  were 
interested  in  examining  cause  and  effect  relationships  between  computer  support  for 
multidisciplinary  design  and  effective  collaboration.  In  addition  we  felt  an  experimental  paradigm 
would  allow  for  comparisons  between  different  computer  tools  to  support  collaboration.  The  next 
two  sections  describe  the  development  of  the  research  paradigm  focusing  on  two  key  steps;  finding 
a  design  problem  and  eliciting  knowledge  from  designers. 
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FINDING  A  DESIGN  PROBLEM 


Designing  a  research  paradigm  to  study  collaborative  design  issues  involved  finding  a 
design  problem  that  could  be  developed  or  adapted  into  an  experimental  task.  A  literature  review 
was  conducted  to  find  a  design  problem  that  could  be  adapted  for  use  in  our  research  paradigm. 
Engineering,  design,  and  human  factors  journals  were  extensively  surveyed,  as  well  as  the  Science 
and  Technology  Index.  In  addition,  we  conducted  computerized  searches  of  the  PSYCHLit  and 
ERIC  databases. 

To  be  considered  as  a  task  candidate,  design  problems  were  judged  in  relation  to  five  criteria 
established  prior  to  our  literature  review.  The  first  criterion  was  that  the  task  had  to  be  based  on  a 
"real  world"  design  problem.  This  "real  world"  perspective  was  driven  by  the  desire  to  produce  an 
experimental  context  that  was  relevant  and  meaningful  for  design  teams  to  participate  in.  Also,  this 
would  enable  research  to  be  undertaken  in  both  field  and  laboratory  settings.  In  addition,  a  "real 
world"  based  task  would  increase  the  external  validity  of  the  task  enhancing  the  generalizability  of 
future  research. 

The  second  criterion  was  that  the  problem  had  to  be  multidisciplinary  in  nature.  This  meant 
that  the  design  problem  had  to  involve  consideration  of  various  disciplines.  Therefore,  it  had  to  be 
sufficiently  complex  so  that  knowledge  from  more  than  one  discipline  would  be  necessary  to 
complete  the  design.  The  disciplines  that  might  be  involved  in  such  a  design  would  be 
management,  marketing,  engineering  (i.e.,  electrical,  computer,  human  factors,  industrial,  etc.), 
psychology  (i.e.,  experimental,  social,  human  factors,  etc). 

Third,  the  problem  had  to  incorporate  or  include  consideration  of  human  factors  issues 
(e.g.,  display  design  issues,  human-computer  interaction  issues,  mental  workload  issues, 
ergonomics  issues,  anthropometry  issues,  etc).  This  criterion  was  included  because  of  its 
relevance  to  the  overall  purpose  of  our  research  team.  Our  research  team  was  interested  in  how 
human  factors  information  gets  incorporated  into  collaborative  design  projects.  We  hoped  this 
knowledge  would  ultimately  contribute  to  the  development  of  groupware  products  that  facilitate  the 
retrieval  and  incorporation  of  human  factors  information  and  expertise  into  the  design  process. 

Fourth,  we  wanted  a  design  problem  that  had  the  potential  to  be  completed  both  in  an 
individual  and  team  context.  The  task  had  to  involve  information  from  a  variety  of  perspectives 
such  that  a  team  could  work  on  it  without  perceiving  the  task  as  trivial.  At  the  same  time,  the  task 
had  to  have  the  potential  to  be  accomplished  by  a  single  individual.  This  would  provide  flexibility 
in  designing  future  experiments  (e.g.,  multiple  levels  of  analysis). 

Fifth,  design  professionals,  as  well  as,  university  students  must  be  able  to  complete  the 
problem.  This  meant  that  the  problem  should  be  relevant  and  meaningful  to  a  student,  as  well  as 
interesting  and  engaging  for  design  professionals.  Ideally,  the  problem  would  have  characteristics 
that  were  familiar  to  both  university  students  and  professional  designers. 

Forty-one  design  problems  were  selected  for  consideration  using  these  criteria  (See  Table 
1).  The  majority  of  these  design  problems  had  been  used  as  instructional  projects  in  college  level 
design  and  engineering  courses.  Some  were  actual  on-going  design  projects. 

From  these  problems  we  selected  the  task  of  designing  a  navigation  display  for  an 
automobile  (Dingus,  1990).  This  design  problem  satisfied  all  of  the  pre-established  criteria.  First, 
designing  a  navigation  system  for  an  automobile  was  a  real  design  project.  Several  systems  have 
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been  designed  and  some  are  currently  being  tested.  Second,  this  design  problem  required  the  input 
of  many  disciplines  (e.g.,  engineering,  psychology,  hardware,  software,  etc.).  Third,  human 
factors  issues  (e.g.,  human-computer  interaction  issues,  display  design  issues,  etc.)  were  taken  into 
consideration  in  previous  design  endeavors  of  automobile  navigation  systems.  Fourth,  we  felt  that 
the  design  could  be  completed  by  both  individuals  and  teams  of  designers.  Fifth,  the  design 
problem  focused  on  a  system  to  aid  individuals  in  driving  and  navigating  an  automobile.  Because 
these  behaviors  are  likely  to  be  familiar  to  both  designers  and  students,  we  felt  that  it  had  the 
potential  to  be  an  interesting  and  engaging  experimental  task  for  both  groups. 
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Table  1.  List  and  description  of  design  problems. 

Problem _ Description _  HFIssues  Considerations  Teams 


Moving 

Map 

Naviga¬ 

tion 

System 

(Dingus, 

1990) 

-automobile  navigation 
interface 

-dual  task  consisting  of  visual 
and  control  components 

-control  theory 

-visual  display 

-workload 

-attentional 

demands 

-HCI 

-Dual  task 

-time  (2-3  weeks) 
-initial  member 
competitiveness 
-groupthink  type  of 
phenomenon 

Yes 

3  per 
team 

Easy- 

Banker 

(Ballay, 

1987) 

-payment  of  credit  card  bills 
by  modem  hookup  to  the  bank 
-consisted  of  cardreader, 
keypad,  led  display,  voice 
recognition  cell 
-design  observed  in  traditional 
and  CAD  environment 

-ergonomic  issues 
-HCI 

-visual  display 
-manual  control 

Must  meet 
requirements: 

1)  HF  and 

Usability 

2)  functional 
specifications 

3)  budget  &  quality 

4)  physical  form 

5)  graphic 
presentation 
(marketing) 

No 

Wheel¬ 
chair  Lap 
Tray 

(Miller  & 
Hyman, 

1989) 

-lap  tray  for  a  speech 
generating  communication 
device 

-designed  for  woman  with  CP 
and  only  head  control 

-ergonomic  issues 
-ease  of  use 
-safety 
-usability 
-size 

-Must  meet  all  HF 
requirements 
-approved  by 
rehabilitation  staff 
&  faculty 
-economical 

Yes 

less 
than  5 

Foot 

Pedal 

Commu¬ 

nication 

System 

(Miller  & 
Hyman, 

1989) 

-communication  device  for  CP 
woman  with  no  control 
-Foot  pedal  communication 
device  was  developed  to  alert 
others 

-ergonomic  issues 

-reliability 

-safety 

-size 

-ease  of  use 

-Must  meet  all  HF 
requirements 
-approved  by 
rehabilitation  staff 
&  faculty 
-economical 

Yes 

less 
than  5 
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otonze 
Wheel¬ 
chair 
Simulator 

(Miller  & 

Hyman, 

1989) 


(Moray, 

1989) 


Board- 

game 

(Fai,  1989) 


Work¬ 

station: 

Mobile 

Ground 

Shelter 

(Frey, 

1990) 


Commer¬ 

cial 

Airline 

Dis¬ 

patcher 

(e-mail) 


-designed  a  motonzed 
simulator  for  joystick  training 
for  young  children  who  will 
need  wheelchairs  later  in  life 

-ergonomic  issues 

-reliability 

-safety 

-size 

-training  usefulness 

-Engineering  and  Psychology 
students  collaborated  to  design 
a  chemical  process  plant 
-Instructor  tried  to  provide 
"realism"  through  letters  from 
CEO  of  Chemical  Co  etc. 

-signal  detection 
-control  theory 
-task  analysis 
-workload 
-visual  display 
selection 
-auditory  display 
selection 
-safety 

-design  for  opening  a  Durian 
(thick-skinned)  tropical  fruit 
-design  based  on  pulling, 
twisting,  and  pressing 

-ergonomic  issues 
-ease  of  use 
-safety 

-one  student  developed  and 
built  a  3-d  boardgame 
-interdisciplinary  aspect: 

1)  industrial  design 

2)  engineering  design 

3)  manufacturing  engineer 

4)  marketing 

-color 
-attention 
-ergonomic  issues 

-design  of  a  mobile  ground 
shelter 

-used  an  iterative  process  of 
CAD  and  foam  "life  size" 
mock-ups(4)  to  design  MGS 

-habitability 
-operation^  utility 
-workspace  design 
-visual  display 
selection 
-auditory  display 
selection 

-Design  of  a  dispatcher's 

workstation 

-student  project 

-HCI 

-visual  displays 
-cooperative 
problem-solving 
-auditory  displays 

-  -ust  meet  afl  HF 
requirements 
-approved  by 
rehabilitation  staff 
&  faculty 
-economical 


-com.petitiveness 
amon^g  members 
-time 
-efficient 


size 

not 

stated 


-time 

-materials  (less 
metal  the  better) 
-economic 


-limited  expertise 
outside  their  own 
field 
-time 


-Access  to  users. 


size 

not 

stated 


Personnel  I  -Modeling  oi  contaminated  site  I  -mtormation  yes 

Database  to  develop  on-base  personnel  management 

database  -HCI 

(e-mail)  -the  information  provided 

(money,  manpower,  and  time) 
was  used  to  base  decisions  on 
direction  of  cleanup  effort 
-collaboration  of 
environmental  engineer  & 
computer  scientist 
-on-going  "real"  project 

Program-  -programmable  thermostat  for  -HCI  issues  -not  ve^  yes 

mable  zoned  home  heating  system  constrained 

Thermo-  -multi-disciplinary  approach  -faked  a  lot  of 

stat  including:  heating-ventilation,  information 

air-conditioning  engineers, 

(e-mail)  industrial/product  designers, 

electrical/electronic  engineers, 

HCI  designers,  and  marketing 
-Project  for  HCI  students 

Distance  -design  of  a  program  of  "long  -visual  presentation  -time  yes 

Education  distance"  education  (or  remote  -computer-mediated  -distance 

education)  communication  -technology 

(e-mail)  -course  in  finance  -learning 

-team  effort  consisting  of  -training 

manager,  SME,  editor,  visual 
designer,  and  instructional 
designer  at  a  minimum 

Precision  -evaluation  of  an  assembly  -safety  issues  -Possible  social  yes. 

Train  process  for  a  180  part  model  -manipulability  of  loafing 

Assembly  train  parts  5  per 

-used  "ease  of  assembly"  rules  group 

(Busch-  for  evaluation  of  assembly 

mann  process 

&Weib- 
mantel, 

1990) _ 

Deepsea  -reliability  of  sonar,  detection,  -HCI 

Salvage  &  location  of  vessel  -visual  display 

-project  to  demonstrate  -auditoiy  display. 

(Kantowitz,  calculating  reliability  in  serial  -reliability 

Sorkin,  and  parallel  systems 

Shively,  &  -rec^culation  methods  after 

Payne,  adding  or  removing 

1983)  components _ 
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emer¬ 

gency 

Vehicle 

(Kantowitz, 
et  al,  1983) 

-design  ot  an  auditory  alarm  to 
indicate  vehicle  in  reverse 
(VIR) 

Controls 

(Kantowitz, 
et  al,  1983) 

-redesign  of  control  panel  to 
improve  accessibility  as 
measured  by  "index  of 
accessibility" 

Data 

Entry 

(Kantowitz, 
et  al,  1983) 

-design  or  selection  of  a  data 
entry  device 

Floor 

Plans 

(Kantowitz, 
et  al,  1983) 

-evaluation  of  house  floor 
plans 

Airport 

Terminal 

(Kantowitz, 
et  al,  1983) 

-design  of  airport  terminal 

Multi¬ 

functional 

Remote 

Controller 

(Tang, 

1991) 

-design  of  a  unified  remote 
control  that  controls  3  devices 
from  three  specified  categories 
(e.g.  stereo  receiver,  TV, 

VCR) 

Laser 

Printer 

(Dingus, 

1990) 

-redesign  of  a  laser  printer 
interface 

-develop  a  usability  test  plan 
-redesign  included  controls, 
display,  menus,  messages, 
and  documentation 

Ground 

Trans¬ 

porter 

Cab 

Controls 

(Dingus, 

1990) 

-design  of  cab  controls  for 
large  ground  transporter 
-develop  test  plan 
-construct  mock-ups 
-make  simulation 
recommendations 

-auaiiory  aispiay 

-visual  display 

-auditory 

localization 

-attention 

-workload 


-ergonomic  issues 
-eontrol  layout 


-HCI 

-visual  display 
-training 
-attention 
-workload 


-physical  layout 

-functionality 

-usability 


-physical  layout 
-workspace  design 
-safety 


-visual  display 
-HCI  issues 
-control  issues 
-ergonomic  issues 


-visual  display 
selection 
-auditory  display 
selection 
-HCI  issues 
hvsical  lavout 


-control  theory  & 
layout 

-ergonomic  issues 

-visual  display 

selection 

-workload 

-attentional 

demands 


-cost 

-software  available 


-cost 

-architectural 

-aesthetics 


-cost 

-aesthetics 


-all  participants 
were  Mechanical 
Engineering 
graduate  students 
-students  had  never 
collaborated 
together  before 

yes, 

3  or  4 
per,  2 
teams 

-time  (2-3  weeks) 
-initial  member 
competitiveness 
-groupthink  type  of 
phenomenon 

yes, 

3  per 
team 

-time  (2-3  weeks) 
-initial  member 
competitiveness 
-groupthink  type  of 
phenomenon 

yes, 

3  per 
team 
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Grocery 

Stand 


(Dingus, 

1990) 

Clinical 

Labs 

(Sanders  & 
McCormick 
1982) 


Metal 

Ingots 

(Sanders  & 
McCormick 
1982) 

Stalk 
Controls 
(Sanders  & 
McCormick 
1982) 

Soldering 

Iron 

(Sanders  & 

McCormick, 

1982) 

Wheel¬ 

barrow 


-design  or  a  simple  soitware 
application  for  use  by  novices 
-develop  usability  test 
-determine  alternate  designs 

-redesign  of  a  grocery  store 
checkout  stand 


-design  information  flow  and 
network  in  labs 
-analyze  the  information 
receiving,  information  storage, 
information  processing,  and 
decision  malang,  as  well  as 
the  action  functions  of  the  lab. 


-in  fictitious  manufacturing 
plant  calculate  the  work  pace 
and  cost  of  lifting  in  terms  of 
energy  expended 
-workers  lift  metal  ingots  for 
storage 

-redesign  of  stalk  controls 
-stalk  controls  are  mounted  on 
the  steering  wheel  of  your  car 
and  usually  have  multiple 
controls  (i.e.  cruise  control, 
turn  signals,  etc.) 

-redesign  of  soldering  iron 
because  of  high  accident  rate 
-application  of  principles  of 
practical  tool  design 


-Design  of  a  garden 
wheelbarrow 


(Ledsome, 

1987) 


-HUl  issues 
-visual  display 

yes, 

3  per 
team 

-ergonomic  issues 

-efficiency 

-performance 

yes, 

3  per 
team 

-information 
processing 
-performance 
-decision  making 
-Information 
management 
-task  analysis 
-safety  issues 
-reliability  issues 

-quick  turn  around 
time  on  specimen 
(time) 

-accurate  results 
-correct 

interpretation  of 
results 

-safety 
-performance 
-work  pace 
-efficient 

-physical  workload 
demands 

-cost 

-control  theory 
-ergonomic  issues 
-usability 
-functionality 
-mental  workload 
-reUability 

-cost 

-tool  design 
-ergonomic  issues 
-safety 

-cost 

-ergonomic  issues 
-safety 

-cost 

-materials 

-marketing 

considerations 
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tionist 

(NC- 

Recep) 

(Tang, 

1989) 


Macintosh 

Visualiza¬ 

tion 

(MacViz) 

(Tang, 

1989) 


Custom¬ 
ized  Phone 
(Custom- 
Phone) 

(Tang, 

1989) 


Silk  Swirl 

(Droz,  1991) 


Child 

Finder 

(Droz,  1991) 


-reaesign  oi  a  nypenext 
software  system  (NoteCards) 
to  manage  and  redirect  phone 
messages 


design  of  the  integration  of 
Mac  PC's  into  a  course  called 
Visual  Thinking 


-design  of  a  multiple  function 
telephone  (e.g.  answering 
machine,  call  waiting, 
forwarding,  conferencing) 
-Human  Factors  students 
participated 


-Design  of  a  portable  device 
that  washes,  rinses,  and  drys 
delicate  apparel 
-graduate  &  undergraduates 
participated 
-simultaneous 

multidisciplinary  approach  to 
design 


design  of  a  device  that 
located  wandering  children 
-graduate  &  undergraduates 
participated 
-simultaneous 

multidisciplinary  approach  to 
design _ 


-learning 

-HCI 


-auditory  display 
-visual  display 
-HCI 
-reliability 


-rehability 
-ergonomic  issues 


-visual  display 
-auditory  display 
-attention 
-safety 
-HCI 


- 1  nour  tor 
discussion 
-1  group  had 
limited 
programming 
experience 
-members  had 
never  collaborated 
together  before 

yes, 

3  per 
team, 

2 

teams 

-1  hour  for 
discussion 
-1st  and  2nd  team 
consisted  of 
essentially  the 
same  members 
-most  members 
had  collaborated 
together  before 

yes, 

3or4 

per 

team, 

2 

teams 

-students  had  never 
collaborated 
together  before 

yes,  3 

per 

team, 

2 

teams 

-teams  consisted  of 

2  persons  from  3 

different 

disciplines 

yes,  6 

per 

team 

-teams  consisted  of 

2  persons  from  3 

different 

disciplines 

yes,  6 

per 

team 

Kwik 

Kooi 

(Droz,  1991) 


EasyOut 
(Droz,  1991) 


Wrinkle 

Away 

(Droz,  1991) 


Snuggler 
(Droz,  1991) 


Dyna 

Bounce 

(Droz,  1991) 


esign  or  a  ponaoie 
hole-punch 

-graduate  &  undergraduates 

participated 

-simultaneous 

multidisciplinary  approach  to 
design 


-design  of  a  device  that  cooled 
a  beverage  in  45  seconds 
without  diluting  it 
-provided  worWng  prototype 
-simultaneous 

multidisciplinary  approach  to 
design  _ 


design  of  a  door  knob  that 
was  easier  for  senior  citizens 
and  handicapped  people  to 
use 

-simultaneous 

multidisciplinary  approach  to 
design 


-design  of  a  portable 
hand-held  fabric  steamer 
-simultaneous 

multidisciplinary  approach  to 
design  _ 


-design  of  a  terry  cloth 
garment/towel  to  aid  adults 
when  giving  baths  to  infants 
-simultaneous 

multidisciplinary  approach  to 
design  _ 


-design  of  new  athletic 
footwear  using  borosilene 
-simultaneous 

multidisciplinary  approach  to 
design 


-ergonomic  issues 


-safety 

-ergonomic  issues 


-ergonormc  issues 
-safety 


-ergonomic  issues 


-teams  consisieu  oi 
2  persons  from  3 
different 
disciplines 


-strict  deadline  of  1 
semester 


-strict  deadline  of  1 
semester 


-strict  deadline  of  1 
semester 


-strict  deadline  of  1 
semester 


-graduate  & 

undergraduates 

participated 

-teams  consisted  of 

2  persons  from  3 

different 

disciplines 


yes,  6 

per 

team 


Note.  "Ergonomic  issues"  refers  to  the  physical  and  physiological  requirements/constraints  of  the 
human  in  human-machine  design. 
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ACQUIRING  KNOWLEDGE  ABOUT  THE  DESIGN  OF 
AN  AUTOMOBILE  NAVIGATION  SYSTEM 

Once  a  design  problem  had  been  chosen,  the  second  phase  of  task  development  began. 
The  second  phase  involved  acquiring  knowledge  or  information  about  the  issues  involved  in 
designing  a  navigation  system  for  an  automobile.  In  particular,  we  focused  on  potential  tradeoffs 
involved  in  designing  within  a  multidisciplinary  team  context.  The  method  and  results  of  this 
knowledge  acquisition  are  described  in  detail  below. 

Method 


Subjects 


Thirteen  design  professionals  were  interviewed  and  concept  mapping  was  used  to 
represent  their  information.  The  design  professionals  included  human  factors  psychologists  and 
engineers,  a  software  specialist,  a  display  hardware  specialist,  an  electrical  engineer,  and  an 
industrial  engineer. 

Procedure 


An  interactive  interview  format  was  used  to  elicit  knowledge  from  subject  matter  experts 
(in  this  case  design  experts)  about  our  design  problem.  Concept  Mapping  (McNeese,  Zaff,  Peio, 
Snyder,  Duncan,  &  McFarren,  1990;  Novak  &  Gowin,  1984)  was  used  to  represent  this 
knowledge.  Concept  maps  are  graphical  networks  of  concept  nodes  and  links.  Concept  nodes 
represent  actions,  events,  or  objects  and  are  connected  by  various  relational  links.  These  relational 
links  convey  information  about  the  interconnection  between  two  concept  nodes  and  usually  are 
prepositions  or  verbs  (McNeese,  et  al.,  1990).  We  focused  on  the  concept-relation-concept  unit 
(i.e.,  a  concept  "triplet")  as  our  primary  unit  of  examination. 

Sessions  were  conducted  in  a  conference  room  that  had  been  modified  for  the  purpose  of 
these  interviews  and  concept  mapping.  The  room  contained  several  whiteboards  fastened  to  the 
walls.  A  Macintosh  computer  was  located  on  a  conference  table  in  the  center  of  the  room.  The 
Macintosh  was  used  to  input  a  computerized  version  of  each  expert's  map  for  later  analysis.  The 
application  program  used  for  this  purpose  was  called  the  Concept  Interpreter  and  was  developed  at 
Armstrong  Laboratories  to  facilitate  the  recording  and  analysis  of  concept  maps  (Snyder,  et  al., 
1991).  In  addition,  sessions  were  audio  taped  for  later  review  and  analysis. 

Involved  in  each  concept  mapping  session  was  a  design  expert,  an  interviewer,  and  an 
additional  panel  of  researchers  associated  with  the  project.  The  interviewer  converted  the 
knowledge  elicited  from  the  expert  into  a  concept  map.  The  additional  panel  of  researchers  served 
to  elicit  additional  information  from  the  expert  as  needed.  The  panel  used  probe  questions  to  clarify 
or  expand  existing  concepts. 

At  the  onset  of  the  concept  mapping  session,  experts  were  seated  at  a  conference  table. 

The  concept  mapper  began  by  giving  a  brief  introduction  to  concept  mapping  and  described  the 
purpose  of  the  interview.  This  included  conveying  information  concerning  our  goal  to  construct  a 
research  paradigm.  At  this  point,  the  concept  mapping  interview  started. 

During  the  concept  mapping  sessions,  the  information  relayed  by  the  expert  was  drawn 
onto  the  whiteboards  so  that  the  expert  and  the  interviewer  could  view  it  simultaneously.  The 
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expert  was  encouraged  to  interact  with  the  concept  map  by  suggesting  changes  and  additions. 

Also,  the  expert  was  encouraged  to  elaborate  on  information  already  represented  in  the  map  to 
clarify  any  “fuzzy”  areas.  Each  concept  mapping  session  took  approximately  one  to  three  hours. 

The  rationale  behind  using  this  format  was  threefold.  First,  the  concept  map  served  as  an 
external  memory  aid  indicating  to  the  expert  what  has  been  discussed  and  stimulating  the  recall  of 
additional  information  (McNeese,  et  al.,  1990).  Any  misunderstandings  or  misinterpretations  that 
the  interviewer  had  could  be  corrected  "on-line"  by  the  expert.  Second,  the  external  representation 
of  knowledge  was  available  to  the  expert  to  help  organize  the  information  that  had  been 
communicated.  Third,  concept  mapping  allowed  the  interviewer  to  locate  and  identify  central  issues 
and  concepts  nodes  within  a  given  subject  area.  The  interviewer  could  prompt  the  expert  for 
additional  information  pertaining  to  these  issues.  Usually,  as  design  experts  interacted  with  the 
concept  maps  more,  the  quality  and  quantity  of  the  elicited  information  increased. 

Results 

The  concept  interpreter  matrix  is  presented  in  Figure  1 .  The  matrix  indicates  the  number  of 
concepts  and  links  in  each  map.  The  number  of  concepts  discussed  by  each  expert  ranged  from  77 
to  191.  The  number  of  triplets  (i.e.,  links)  ranged  from  79  to  207.  The  matrix  also  indicates 
whether  reference  to  a  particular  category  appeared  in  each  of  the  13  concept  maps.  A  dot  indicates 
that  an  element  of  that  category  was  mentioned  once.  A  circle  and  a  dot  indicate  that  two  or  more 
elements  from  that  category  were  discussed.  As  can  be  seen  from  Figure  1,  there  was  a  good  deal 
of  consistency  across  the  experts.  The  experts  covered  many  of  the  same  issues.  The  next  section 
summarizes  the  key  issues  identified  by  the  experts. 

To  facilitate  the  discussion,  the  categories  from  the  concept  interpreter  were  broken  down 
into  two  groupings:  process  issues  and  tradeoff  issues.  Process  issues  focused  on  identifying 
team  members  (i.e.,  who  is  on  the  team),  the  timeline  of  a  "typical"  design,  and  the  objective  or 
design  mission.  Tradeoff  issues  focused  primarily  on  the  types  of  constraints  and  tradeoffs 
different  team  members  might  face  in  designing  an  automobile  navigation  system.  Both  types  of 
information  were  useful  for  building  the  task.  The  process  information  helped  to  specify  what 
types  of  disciplines  (e.g.,  software  engineers,  marketing  analyst,  program  manager)  should  be 
represented  in  the  research  paradigm,  the  steps  involved  in  designing  a  navigation  system  for  an 
automobile,  and  what  was  a  reasonable  task  for  designers  to  do  in  a  limited  amount  of  time.  The 
tradeoff  issues  helped  identify  the  structure  of  the  task  and  provide  "real  world"  information  for 
creating  the  task  materials.  Each  grouping  will  be  discussed  in  more  detail  below. 

Process  Issues 

Team  Composition.  Six  disciplines  were  mentioned  consistently  across  the  maps.  Over  half  of 
the  experts  who  discussed  team  composition  indicated  these  disciplines.  The  prototypical  design 
team  included:  1)  a  human  factors  psychologist  /  engineer,  2)  a  hardware  /  display  engineer,  3)  a 
software  engineer  /  programmer,  4)  a  manager,  5)  a  marketing  analyst  /  user  representative,  and  6) 
a  system  /  safety  specialist. 
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Figure  1 :  Concept  Interpreter  Matrix 


Timeline  Phases.  Four  phases  were  discernible  from  the  matrix  results.  The  steps  identified 
by  the  experts  were:  1)  marketing  definition  phase,  2)  team  assembly  ph^e,  3)  developmental 
planning  phase,  4)  full  scale  development  and  prototyping  phase,  and  5)  implementation  phase. 
According  to  the  experts,  the  marketing  definition  phase  would  involve  the  identification  of  a  niche 
or  marketing  need  for  the  product.  This  would  include  conducting  a  small  feasibility  study  to 
assess  whether  the  product  could  be  produced  profitably.  In  the  second  phase,  team  members 
would  be  identified  and  assigned  responsibilities.  Typically  the  team  members  would  represent  the 
disciplines  discussed  above.  During  the  developmental  planning  phase,  the  team  would  stipulate 
the  specifications  and  performance  requirements  for  the  product.  The  full  scale  development  phase 
would  be  an  iterative  process  that  involves  prototyping,  identifying  problems,  correcting  problems, 
and  refining  the  design.  This  would  be  the  phase  where  most  design  tradeoffs  and  bottlenecks 
would  become  apparent.  During  this  phase,  beta  versions  of  the  product  would  be  created,  tested, 
and  evaluated.  The  final  phase,  implementation,  would  involve  releasing  the  final  product. 

Tradeoff  Issues 


This  section  discusses  design  tradeoffs  identified  by  the  experts.  For  the  purposes  of  this 
paper,  tradeoffs  were  defined  as  issues  where  two  or  more  disciplines  were  needed  to  provide 
information  for  final  design  decisions.  Design  tradeoffs  could  be  issues  where  the  needs  or 
constraints  of  one  discipline  override  the  needs  or  constraints  of  another,  or  just  where  input  is 
needed  from  multiple  disciplines.  Owing  to  the  complexity  of  relationships  among  disciplines, 
issues,  and  tradeoffs,  we  have  organized  the  material  and  our  description  according  to  the  schema 
of  Table  2.  Four  major  categories  of  design  tradeoffs  were  identified  by  the  Experts:  a)  Display 
Hardware,  b)  Display  Format,  c)  Navigation  System,  and  d)  Context.  Each  of  these  categories 
contained  major  issues  (indicated  by  upper-case  letters  in  Table  2)  and  each  of  these  major  issues 
had  subissues  (indicated  by  lower-case  letters  in  Table  2).  These  issues  and  subissues  are  listed  in 
the  leftmost  column  of  Table  2.  The  middle  columns  indicate  the  disciplines  identified  as  part  of  the 
design  process.  Disciplines  concerned  with  tradeoffs  for  an  issue  or  subissue  are  darkened  (within 
a  row)  to  indicate  a  common  concern  or  interest.  The  row  beside  major  issues  (upper-case  letters) 
indicate  the  overall  level  of  interaction  between  the  various  disciplines.  The  rows  beside  the 
subissues  (lower-case  letters)  indicate  the  specific  disciplines  that  have  common  interests  for  the 
specific  subissue.  At  the  rightmost  column  section  numbers  for  the  issues  and  subissues  are  listed. 
These  section  numbers  refer  the  reader  to  more  detailed  text  descriptions  of  the  design  tradeoffs  that 
follow  Table  2.  Each  text  section  is  structured  so  that  it  may  be  read  independent  of  other  sections. 
If  text  sections  are  read  linearly,  a  certain  amount  of  redundancy  should  be  expected. 
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Table  2.  Tradeoff  Issues  and  Sub-Issues  with  respect  to  Discipline  Perspective. 
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Display  Hardware.  The  experts  identified  several  issues  concerning  the  display  hardware. 

This  is  hardware  primarily  used  for  displaying  information  to  the  driver.  This  area  focused  mostly 
on  technical  constraints  of  the  design. 

I.  Display  Type.  The  experts  identified  several  issues  with  respect  to  the  display  type  used. 
Display  type  refers  to  the  actual  physical  monitor  type  to  be  used  to  display  the  moving  navigation 
map. 


a.  The  display  size  may  affect  the  readability  of  text  and  images.  The  larger  the  size  of  the 
display,  the  more  readable  it  would  be.  The  Human  Factors  Expert  would  want  a  larger  display. 
The  Hardware  Expert,  however,  would  have  considerable  say  into  the  display  size  used. 

b.  Display  resolution  affects  the  readability  of  characters  on  the  display  surface.  If 
resolution  is  low,  readability  would  be  negatively  affected.  Thus,  the  Human  Factors  Expert  would 
be  concerned  with  resolution  and  its  impact  on  readability.  In  addition,  the  Software  Expert  would 
need  to  consider  the  display  resolution  limitations  when  developing  software  for  the  display. 

c.  Display  type,  power  supply  type,  and  cooling  equipment  type  are  major  concerns  when 
considering  electrical  and  system  compatibility.  Electrical  compatibility  of  the  navigation  unit  must 
be  considered  with  respect  to  the  vehicle’s  current  electrical  systems.  Also,  physicd  fit  of  the 
display,  power  supply,  and  cooling  equipment  must  be  considered  and  planned  for.  These  would 
be  issues  for  the  System  /  Safety  Expert.  Also,  integration  of  these  subsystem  components  must  be 
considered  with  respect  to  the  navigation  system  in  isolation  and  would  ^  handled  by  the 
Hardware  Expert. 

d.  Retail  cost  of  the  navigation  unit  is  partially  based  on  a  combination  of  the  project  costs 
and  an  expectation  of  what  the  end  user  is  willing  to  pay  for  the  system.  Increases  in  project  cost, 
would  lead  to  increases  in  retail  cost.  The  project  cost  must  be  balanced  against  the  projected 
amount  the  end  user  is  willing  to  pay  for  the  system.  The  Management  Expert  would  be 
responsible  for  keeping  the  project  costs  to  a  minimum  while  the  Marketing  /  User  Expert  would  be 
responsible  for  determining  a  fair  price  (partially  based  on  the  willingness  factor)  for  the  system  and 
its  installation. 

e.  Display  type  partially  determines  the  level  of  display  resolution.  Various  display  types 
offer  differing  levels  of  resolution.  The  display  type  decision  would  primarily  be  made  by  the 
Hardware  Expert.  The  Software  Expert,  however,  must  know  the  resolution  of  the  selected  display 
to  develop  appropriate  software. 

n.  Color  Versus  Monochrome  Screen.  The  experts  identified  two  options  for  monitor 
screen  type  that  would  affect  color.  The  two  options  were  either  a  color  screen  or  a  monochrome 
screen.  Screen  choice  would  most  likely  be  limited  to  either  LCD  (Liquid  Crystal  Display)  or  CRT 
(Cathode  Ray  Display)  type  monitors.  CRT  monitors  have  greater  color  capabilities  than  LCD 
monitors. 


a.  The  update  rate,  or  screen  refresh  rate,  of  the  monitor  is  important  to  consider  in 
developing  this  system.  CRTs  have  slower  update  rates  than  LCDs.  TTie  decision  concerning 
monitor  type  would  primarily  be  the  responsibility  of  the  Hardware  Expert.  The  Software  Expert 
must  take  into  consideration  update  rates  of  specific  monitors  when  developing  software  for  the 
system. 

b.  Project  cost  is  affected  by  the  color  level  wanted  in  the  monitor.  The  more  colors  that 
the  monitor  must  support,  the  more  expensive  the  monitor  would  be.  This  added  expense  would  be 
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added  into  project  costs.  CRTs  can  generate  more  colors  and  would  be  less  expensive  than  LCDs. 
Thus,  project  costs  would  increase  if  LCDs  were  chosen.  Decisions  concerning  monitor  type 
would  primarily  be  made  by  the  Hardware  Expert.  Any  decision  that  increases  project  costs  would 
concern  the  Management  Expert. 

c.  In  general,  end  users  prefer  color  in  their  displays.  Thus,  a  color  monitor  has  greater 
utility  from  the  perspective  of  the  Marketing/User  Expert.  The  decision  concerning  the  type  of 
monitor,  however,  resides  primarily  with  the  Hardware  Expert. 

d.  Using  many  colors  in  a  display  would  increase  the  program  complexity,  but  tends  to  aid 
in  the  readability  of  text  and  identification  of  objects.  In  turn,  this  leads  to  reduced  mental  workload 
for  the  operator  which  would  concern  the  Human  Factors  Expert.  The  Software  Expert,  however, 
would  be  concerned  with  the  increased  software  complexity  that  results  from  supporting  many 
colors. 


e.  An  increase  in  software  complexity  would  result  if  many  colors  were  used  in  the  display. 
Use  of  color  in  the  display  would  be  preferred  by  the  Marketing  /User  Expert  due  to  user 
preferences  for  color.  Because  color  is  associated  with  increased  program  complexity,  the 
Software  Expert  may  be  at  odds  with  this  preference. 

III.  Control  Issues.  The  experts  identified  several  issues  concerning  system  control  issues. 
Control  issues  deal  with  how  the  operator  inputs  commands  into  the  system. 

a.  Touch  screen  control  inputs  could  be  used  in  the  system,  but  would  increase  project 
cost.  The  decision  to  use  a  touch  screen  would  be  made  primarily  by  the  Hardware  Expert.  Any 
increase  in  cost  associated  with  the  installation  of  a  touch  screen  would  also  concern  the 
Management  Expert. 

b.  The  complexity  of  the  programming  would  increase  if  a  touch  screen  control  input  were 
used  in  the  system.  Although  a  touch  screen  might  be  a  desirable  option  for  the  Hardware  Expert, 
the  Software  Expert  must  write  software  to  fit  the  control  device.  Thus,  the  Hardware  Expert  and 
the  Software  Expert  may  be  at  odds. 

c.  A  touch  screen  may  become  too  hot  to  touch  during  normal  operation  of  the  navigation 
system.  Thus,  desirability  of  the  touch  screen  from  the  Hardware  Expert’s  perspective  must  be 
considered  with  respect  to  the  System  /  Safety  Expert’s  concerns  for  developing  a  safe  and  hazard 
free  system. 

d.  Display  access,  distraction  issues,  and  reach  /  anthropometry  issues  are  affected  by  the 
location  of  control  inputs  with  respect  to  the  driver.  Poor  location  of  control  surfaces  can  lead  to 
difficulty  in  viewing  the  display,  distraction  away  from  the  primary  task  of  driving  the  vehicle,  and 
awkward  control  of  the  display.  The  Human  Factors  Expert  would  be  concerned  primarily  with 
these  issues,  as  would  the  System  /  Safety  Expert  due  to  their  impact  on  driver  safety. 

e.  The  development  of  user  friendly  control  configurations  that  are  appealing  to  customers 
must  be  balanced  against  issues  concerning  display  access,  distraction,  and  reach  /  anthropometry 
concerns.  Sometimes  these  factors  may  be  at  odds.  A  configuration  that  is  accessible,  offers 
reduced  distraction,  and  has  adequate  reachability  may  not  be  appealing  or  intuitive  enough  for  the 
user  to  operate.  The  Marketing  /  User  Expert  would  be  concerned  with  the  attractiveness  of  the 
control  configuration  to  the  user,  while  the  Human  Factors  Expert  would  be  concerned  with  its 
usability. 
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Display  Format.  The  experts  identified  several  issues  concerning  the  display  format  used  to 
present  information  to  the  driver. 

IV.  Track-Up  Versus  North-Up  Map  Orientation.  The  experts  identified  two  options  for 
map  orientation.  The  first  option  was  a  track-up  orientation.  In  a  track-up  orientation,  the  car  icon 
on  the  display  is  always  oriented  in  the  direction  of  travel.  Therefore,  the  map  must  rotate  around 
the  car  to  keep  constant  orientation.  The  second  option  was  a  north-up  orientation.  In  a  north-up 
orientation,  the  map  remains  in  a  constant  orientation  and  the  car  icon  would  rotate  with  respect  to 
the  direction  traveled. 

a.  Selection  of  display  format  can  affect  the  level  of  program  complexity  required  to  present 
the  format.  The  greater  the  complexity,  the  more  time  required  to  write  the  software  and  the  higher 
the  project  costs.  Both  track-up  and  north-up  format  orientations  have  unique  attributes  that  would 
require  special  software.  Increasing  the  project  cost  and  schedule  would  be  an  issue  for  the 
Management  Expert,  while  the  Software  Expert  would  be  more  concerned  with  the  programming 
complexity. 

b.  Imaging  generation  techniques  used  to  present  graphics  require  varying  levels  of 
programming  complexity.  Raster  /  bitmap  techniques  would  be  preferable  from  a  Marketing  /  User 
perspective  because  they  generate  more  realistic  graphics.  From  the  Software  Expert’s  perspective, 
however,  raster  /  bitmap  techniques  are  harder  to  implement  than  other  techniques  (e.g.,  vector 
drawing). 

V.  Menus.  The  experts  identified  several  issues  with  respect  to  the  menu  structure  to  be 
used.  Menu  issues  are  concerned  with  the  organization  and  hierarchical  ordering  of  commands  and 
the  users’  ability  to  access  and  input  necessary  information  using  the  navigation  system’s  interface. 

a.  A  “simple”  interface  has  a  command  structure  that  is  straightforward,  is  not  distracting, 
and  has  relatively  few  control  inputs.  “Simple”  menuing  interfaces  involve  greater  complexity 
because  of  “behind  the  scenes”  programming  to  simplify  user  control  inputs.  The  Human  Factors 
Expert  and  Marketing  /  User  Expert  strongly  prefer  a  “simple”  interface.  Increased  program 
complexity,  however,  would  concern  Software  Experts  because  they  must  write  the  software. 

b.  Increasing  the  level  of  program  complexity  would  increase  project  costs  and  extend  the 
project  timeline.  Increased  complexity  of  the  software  may  result  if  a  “simple”  interface  is  wanted. 
The  Management  Expert  would  be  concerned  with  increases  in  project  cost  and  schedule,  while  the 
Software  expert  would  be  concerned  with  the  effects  of  increasing  program  complexity. 

VI.  Variable  Zoom  Issues.  The  experts  identified  several  issues  concerning  the  use  of 
variable  zoom.  These  issues  dealt  with  the  relative  advantages  and  disadvantages  of  giving  the  user 
the  option  to  zoom  in  on  particular  location  details.  Using  a  variable  zoom  option  assumes  the 
decision  to  incorporate  a  visual  display  into  the  system. 

a.  In  designing  software,  the  processor  speed  limitations  must  be  considered  when 
attempting  to  implement  zoom  features.  The  zoom  features  may  be  limited  by  the  CPU  speed.  The 
Hardware  Expert  would  be  the  most  knowledgeable  about  the  CPU  and  would  interact  with  the 
Software  Expert  to  create  the  required  software  needed  for  zoom  features. 

b.  The  amount  and  type  of  information  needed  for  zoom  features  would  dictate  the  type  of 
database  and  the  complexity  of  the  retrieval  /  storage  mechanisms  required.  The  more  complex  the 


25 


database,  the  more  expensive  it  would  be.  This  added  cost  would  most  likely  be  absorbed  into  the 
system’s  retail  cost.  This  would  concern  Marketing  /  User  Experts  since  they  want  to  keep  the 
system  cost  affordable  for  the  end  users.  The  choice  of  database  and  retrieve  /  storage  mechanisms 
would  most  likely  fall  to  the  Hardware  Expert. 

c.  The  more  detailed  the  level  of  information  needed  for  zoom  features,  the  more  monetary 
cost  that  would  be  incurred  in  gathering  the  necessary  information.  Also,  a  more  complex  database 
and  retrieval  /  storage  mechanism  would  be  required.  This  would  increase  project  costs,  because 
the  database  would  be  more  expensive.  The  Management  Expert  would  be  concerned  with  the  cost 
of  the  required  database  and  the  cost  accrued  in  information  gathering  activities.  The  choice  of 
database  and  associated  retrieval  /  storage  mechanisms  would  likely  be  made  by  the  Hardware 
Expert. 


d.  The  data  storage  device  type  would  be  constrained  by  the  physical  fit  of  the  device  into 
the  vehicle  itself.  Various  drive  types  are  shaped  differently  and  have  different  options  for 
mounting  and  placement  within  the  vehicle.  This  physical  fit  issue  would  require  input  from  the 
System  /  Safety  Expert.  The  System  /  Safety  Expert  would  likely  consult  the  Hardware  Expert 
because  the  data  storage  device  would  be  a  Hardware  issue. 

e.  Filtering  of  information  may  be  required  to  reduce  the  presentation  of  irrelevant 
information  to  the  driver.  The  filtering  algorithm  /  mechanism  would  likely  increase  the  software 
complexity.  In  addition,  filtering  of  raster  /  bitmap  images  may  prove  to  be  quite  difficult  to 
accomplish  with  software.  Dealing  with  these  issues  would  increase  project  costs.  The  Software 
Expert  would  need  to  develop  filtering  methods  that  filter  information  correctly  and  efficiently.  The 
Management  Expert,  however,  would  be  concerned  with  any  related  additions  to  project  cost. 

f.  Auto-decluttering  would  be  a  useful  feature  in  the  navigational  system  to  reduce  screen 
clutter  when  presenting  traffic  congested  areas.  Cluttered  displays  caused  by  presentation  of  traffic 
congestion  would  increase  the  driver’s  mental  workload.  Mental  workload  would  also  increase  if 
screen  resolution  was  low.  The  screen  may  be  more  difficult  to  interpret  because  images  may  be 
less  well  defined.  The  Human  Factors  Expert  would  want  a  high  resolution  screen  and  an  auto- 
decluttering  mechanism  built  into  the  system  so  that  driver  mental  workload  would  be  reduced.  The 
Hardware  Expert,  however,  would  ultimately  determine  the  screen  resolution  to  be  used. 

g.  If  the  driver  is  presented  with  too  much  information,  information  overload  may  occur. 
Preventing  this  would  require  a  complex  auto-decluttering  software  solution.  The  Human  Factors 
Expert  would  probably  want  this  type  of  feature  to  decrease  the  chances  of  information  overload, 
but  the  Software  Expert  would  be  concerned  with  its  incorporation  into  the  system  because  it  adds 
program  complexity. 

VII.  Visual  Versus  Auditory  Displays.  The  experts  identified  two  format  options  for  how 
information  might  be  displayed  to  the  operator.  The  first  option  was  to  use  a  visual  display.  In  this 
method,  all  information  would  be  presented  via  a  visual  display  surface.  The  second  option  was  to 
use  an  auditory  display.  Information  would  be  presented  to  the  driver  aurally  using  speakers  placed 
in  the  vehicle. 

a.  The  visual  display  type  would  affect  the  software  complexity  required  to  operate  the 
display.  As  the  complexity  of  the  display  increases,  the  complexity  of  the  software  increases.  The 
decision  to  select  the  visud  display  type  would  likely  fall  to  the  Hardware  Expert,  while  the 
Software  Expert  would  deal  with  any  added  programming  complexity. 
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b.  Given  a  specific  visual  display,  the  physical  fit  of  the  display  unit  and  associated 
hardware  must  be  considered  with  respect  to  the  current  vehicle  configuration.  In  other  words,  the 
display  unit,  cabling,  and  other  necessary  hardware  must  fit  into  the  vehicle.  The  System  /  Safety 
Expert  would  need  to  deal  with  this  issue  and  would  likely  consult  with  the  Hardware  Expert  on  the 
required  display  hardware  needed  to  be  placed  within  the  vehicle. 

c.  If  an  auditory  display  were  used  in  the  system,  additional  software  for  use  with  a  speech 
generator  would  need  to  be  created.  The  program  needed  to  operate  a  speech  generator  may  be 
quite  complex.  Generally,  the  more  complex  the  generator,  the  more  complex  the  software  that 
would  be  required.  Thus,  the  Software  Expert  would  be  concerned  with  the  software  required  and 
the  Hardware  Expert  would  be  concerned  with  the  specific  speech  generator  that  would  be  used. 

d.  Overheating  of  the  speech  generator,  both  internal  and  external,  can  adversely  affect  the 
understandability  of  the  speech  produced.  If  understandability  is  poor  due  to  heat  effects,  the  driver 
may  be  attending  too  closely  to  the  voice  and  be  distracted  from  the  primary  task  of  driving.  This 
distraction  issue  would  concern  the  Human  Factors  Expert  and  the  System  /  Safety  Expert.  In 
deciding  which  speech  generator  to  use,  the  Hardware  Expert  would  need  to  consider  the  heat 
limitations  of  the  speech  synthesizer  used  in  the  generator. 

e.  Using  an  auditory  display  would  require  more  complex  software  than  a  visual  display. 
The  production  of  sound  generation  software  would  require  more  resources  and  would  increase  the 
overall  project  cost.  The  Software  Expert  would  be  concerned  with  how  to  create  the  software 
needed,  while  the  Management  Expert  would  be  concerned  with  how  it  would  impact  project  cost. 

f.  Auditory  displays  would  be  desirable  because  they  can  serve  as  aural  reminders  of 
approaching  turns  and  directions  the  driver  must  take.  These  aural  reminders,  however,  rnay  be 
distracting  if  the  driver  has  difficulty  understanding  and  comprehending  the  sound.  In  addition,  use 
of  an  auditory  display  would  increase  project  costs.  The  Human  Factors  Expert  would  be 
concerned  with  any  resulting  distractions,  while  the  Management  Expert  would  be  concerned  with 
increased  costs. 

g.  Poor  understandability  of  the  synthesized  voice  can  be  a  concern  for  two  reasons.  First, 
if  voice  understandability  is  poor,  the  system  may  not  be  usable.  Second,  poor  understandability 
may  distract  operators  from  the  task  of  driving  because  they  spend  time  trying  to  comprehend  the 
voice.  Poor  usability  would  likely  result  in  low  consumer  sales  which  would  be  an  issue  for  the 
Marketing/User  Expert.  The  issue  of  distraction  would  concern  the  Human  Factors  Expert. 

Navigation  Systems.  The  experts  identified  several  common  areas  of  concern  with  the 
Navigation  System.  The  Navigation  System  is  composed  of  the  primary  devices  used  in  plotting, 
tracking,  and  directing  the  path  of  the  vehicle. 

VIII.  GPS  vs.  INS.  In  general,  there  are  two  types  of  navigation  devices  to  be  considered. 
The  first  type  was  an  Inertial  Navigation  System,  or  INS.  In  this  type  of  system,  the  location  and 
direction  of  the  vehicle  are  determined  by  an  internal  compass  and  motion  sensors.  The  second 
type  of  system  was  the  Global  Positioning  System,  or  GPS.  This  type  of  system  relies  on 
information  relayed  from  satellites  to  determine  longitude  and  latitude.  The  position  is  then  plotted 
on  a  map  stored  in  the  database.  The  GPS  system  requires  the  use  of  a  receiver  and  antennae  on  the 
vehicle. 


a.  In  a  GPS  system,  incoming  location  data  must  be  plotted  by  the  navigation  system 
against  the  internal  map  database.  Inaccuracies  /  incongruencies,  however,  may  occur  between 
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position  and  map  database  data.  This  may  lead  to  traffic  accidents  and  other  safety  issues  for  the 
System  /  Safety  Expert.  The  Hardware  Expert  would  be  concerned  with  how  the  system  plots  and 
what  mechanisms  would  be  used. 

b.  Error  checking  capabilities  may  be  needed  to  deal  with  the  inaccuracies  and 
incongmencies  caused  by  difficulties  in  matching  location  and  map  database  information.  This 
capability  would  involve  more  complex  software,  leading  to  increases  in  the  project’s  cost.  Project 
cost  would  be  an  issue  for  the  Management  Expert,  while  the  Software  Expert  would  be  concerned 
with  the  implementation  of  proper  program  mechanisms  to  check  for  errors. 

c.  The  cost  of  the  various  types  of  navigation  systems  must  be  considered  when  deciding 
upon  a  specific  one  to  implement.  For  example,  GPS  systems  are  more  expensive  than  INS 
systems.  On  the  other  hand,  GPS  systems  are  also  more  desirable  because  of  their  better  accuracy. 
The  decision  about  which  system  to  implement  would  likely  reside  with  the  Hardware  Expert. 
Because  cost  would  be  an  issue,  the  Management  Expert  would  also  have  some  input. 

d.  Weight  differences  between  navigation  systems  must  be  considered  with  respect  to  the 
total  system  weight  added  to  the  vehicle.  An  INS  system  would  weigh  more  than  a  GPS  system. 
Consideration  of  weight  would  concern  System  /  Safety  Experts.  They  would  need  to  interact  with 
the  Hardware  Expert,  who  has  primary  responsibility  for  choosing  a  navigation  system. 

e.  It  is  important  to  consider  system  aesthetics  (i.e.,  consumer  appeal)  of  a  selected 
navigation  system  to  avoid  potential  negative  effects  on  final  sales.  If  a  system  is  externally 
unattractive,  consumer  reactions  may  be  negative  and  result  in  poor  sales.  For  example,  the 
antennae  and  receiver  components  of  a  GPS  system  must  be  mounted  to  the  vehicle’s  exterior. 

This  may  cause  the  vehicle  to  look  aesthetically  unappealing.  This  issue  of  consumer  app)eal  would 
be  an  issue  for  the  Marketing  /  User  Expert.  The  Hardware  Expert  would  be  concerned  with  the 
types  of  external  equipment  to  be  mounted  to  the  vehicle. 

Context.  The  experts  identified  several  context  issues  that  would  affect  how  the  system 
operates.  The  context  issues  deal  with  external  or  environmental  variables  the  system  must  be  able 
to  cope  with.  These  issues  include  weather,  glare,  traffic,  and  safety. 

IX.  Weather  Issues.  The  experts  identified  several  issues  with  respect  to  weather  and  its 
impact  on  the  entire  system. 

a.  An  increase  in  mental  workload  may  result  if  software  is  inadequate  at  correcting  poor 
information  due  to  bad  weather  interference.  This  may  increase  the  difficulty  experienced  by  the 
operator  in  interpreting  the  information  correctly.  The  difficulty  may  lead  to  an  increase  in  mental 
workload  which  would  concern  the  Human  Factors  Expert.  The  level,  or  quality,  of  weather 
corrections  would  be  dependent  on  the  ability  of  the  software  to  transparently  correct  errors.  This 
would  concern  the  Software  Expert. 

b.  Reception  of  traffic  information  could  be  affected  by  physical  damage  caused  by 
corrosion  and  weather.  This  could  adversely  affect  the  quality  of  reception  and  increase  the  mental 
workload  of  the  driver  if  provisions  are  not  made  to  correct  for  these  problems.  The  impact  of 
these  factors  on  the  physical  systems  would  concern  the  Hardware  Expert,  and  the  System  /  Safety 
Expert  would  be  concerned  about  how  they  affect  driver  safety.  Additional  workload  caused  by 
trying  to  interpret  the  system  may  distract  the  operator  while  driving  the  vehicle. 
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X.  Safety  Issues.  The  experts  identified  several  issues  with  respect  to  the  overall  safety  of 
the  system. 


a.  Inaccurate  or  incorrect  information  presented  by  the  system  due  to  software  bugs  and 
errors  may  lead  to  traffic  accidents.  The  Management  Expert  and  Marketing/User  Expert  would  be 
concerned  since  lawsuits  may  be  brought  against  the  manufacturers  if  the  fault  lies  with  the  system. 
The  Software  Expert  would  be  concerned  with  attempting  to  correct  any  bugs  with  the  program. 

b.  Design  errors  in  the  system  may  lead  to  human  errors  while  driving.  This  can  be 
potentially  disastrous  because  this  could  lead  to  traffic  accidents.  The  Human  Factors  Expert  would 
be  concerned  with  human  error  caused  by  design  errors.  Management  and  Marketing/User  Experts 
would  be  concerned  with  design  errors  because  any  resulting  traffic  accidents  could  lead  to 
lawsuits. 

XI.  Glare  Issues.  The  experts  identified  several  issues  concerning  screen  glare. 

a.  If  glare  is  present,  the  operator  may  find  it  difficult  to  read  the  display.  This  may 
increase  the  mental  workload  of  the  operator.  Glare  would  be  affected  by  type  of  monitor  and 
curve  of  display  surface.  The  issue  of  readability  would  concern  the  Human  Factors  Expert.  The 
Hardware  Expert  would  probably  choose  the  type  of  monitor  /  display  curvature  and  may  need  to 
consider  the  opinions  of  the  Human  Factors  Expert. 

b.  Improper  display  tilt  can  cause  glare  and  reduce  the  readability  of  the  display  surface.  A 
non-glare  screen  could  be  installed  to  prevent  these  problems,  but  this  would  increase  project  costs. 
The  Hardware  Expert  and  the  Human  Factors  Expert  share  the  same  concerns  about  glare  and  its 
effects  on  readability.  Both  Experts’  would  want  a  non-glare  screen  installed  in  the  system.  The 
Management  Expert,  however,  would  be  concerned  with  any  increased  costs.  The  System  /  Safety 
Expert  would  be  concerned  with  the  danger  of  glare  interfering  with  normal  vision  or  blinding  the 
operator  during  driving. 

Xn.  TrafTic  Issues.  The  experts  identified  a  single  issue  of  common  concern  focused  on 
traffic  issues.  This  concern  was  shared  by  the  Management  and  the  Marketing/User  Experts. 

a.  The  cost  of  transmitting  and  receiving  constant  traffic  updates  to  and  from  the  vehicle 
would  be  expensive.  However,  having  constant  traffic  updates  would  be  more  appealing  to 
customers  and  would  be  wanted  by  the  Marketing/User  Expert.  The  Management  Expert  would  be 
concerned  with  the  added  cost  of  having  this  feature  and  its  effect  on  overall  project  costs. 
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DESCRIPTION  OF  THE  EXPERIMENTAL  TASK:  AUTOMATE 

After  examining  the  information  provided  by  the  experts,  we  narrowed  the  design  problem 
down  to  the  issue  of  designing  an  auditory  display  for  the  automobile  navigation  system.  The 
relevant  tradeoffs  were  drawn  from  the  information  provided  by  the  experts.  The  task  was 
designed  to  study  the  critical  collaborative  issues  of  information  sharing  and  misanalogies. 

Stasser’s  (Stasser  &  Titus,  1985;  1987)  hidden  profile  paradigm  was  modified  for  this  purpose.  In 
the  hidden  profile  paradigm,  decision  makers  are  given  information  about  three  candidates  (e.g., 
job  candidates).  Some  of  the  information  is  shared  among  all  of  the  decision  makers.  Unique 
information  is  given  to  individual  decision  makers.  The  shared  information  favors  one  candidate, 
while  the  combination  of  shared  and  unique  information  favors  a  different  candidate.  Thus,  the 
hidden  profile  can  only  be  discovered  and  the  correct  decision  made  if  the  group  discusses  all  of  the 
information  (both  unique  and  shared).  If  the  group’s  discussion  focuses  on  only  shared 
information,  the  group  is  likely  to  arrive  at  the  wrong  decision. 

This  paradigm  was  modified  for  multidisciplinary  design  teams  by  focusing  on  decision 
alternatives  for  the  auditory  display  of  the  navigation  system.  The  decision  alternatives  were  three 
different  sound  boards  that  could  be  used  to  produce  the  speech  required  for  the  audio  display. 
Appendix  A  shows  the  sound  board  options.  This  information  will  be  shared  among  all  design 
team  members.  In  addition,  information  about  the  design  specifications  (See  Appendix  B)  and 
speech  synthesis  options  (See  Appendix  C)  will  be  shared  with  all  design  team  members. 

Decision  makers  will  be  given  unique  or  unshared  information  that  is  relevant  to  their 
particular  design  background.  Information  for  three  design  backgrounds  are  provided  in 
Appendices  D,  E,  and  F.  For  example,  information  for  a  Human  Factors  Expert  is  presented  in 
Appendix  D.  This  information  focuses  on  the  primary  concerns  of  driver  information  processing 
load  and  speech  intelligibility.  Appendix  E  presents  the  information  for  a  Computer  Engineer.  This 
information  focuses  on  the  primary  concerns  of  data  storage  and  power  consumption.  Appendix  F 
presents  the  information  for  a  System  /  Safety  Engineer  and  focuses  on  the  issues  of  quality  and  fit. 

Embedded  in  the  unique  information  are  critical  pieces  of  knowledge.  If  the  design  team’s 
discussion  focuses  on  only  shared  information,  the  best  design  candidate  of  the  speech  processing 
boards  would  be  the  Voice  Player  because  of  its  low  cost.  It  can  produce  CD  quality  sound, 
appears  to  be  able  to  withstand  the  air  temperatures  specified  in  the  design  specifications,  and 
includes  the  text-to-speech  program.  But,  critical  pieces  of  the  unshared  information  make  this 
board  less  desirable:  1)  the  board  must  withstand  temperatures  found  within  an  automobile  which 
are  more  extreme  than  air  temperatures  (See  Computer  Engineer’s  information  in  Appendix  E)  and 
2)  because  this  board  has  no  compression  eapabilities  it  would  add  to  the  data  storage  requirements 
increasing  the  costs  (See  the  Computer  Engineer’s  information  in  Appendix  E  and  the  System  / 
Safety  Engineer’s  information  in  Appendix  F). 

The  unshared  information  combined  with  the  shared  information  indicate  that  the  Orator 
would  be  the  best  selection.  For  the  team  to  realize  this  they  must  overcome  a  potential  misanalogy 
concerning  the  sarnpling  rate.  The  shared  information  states  that  the  best  sampling  rate  is  44. 1  kHz 
and  that  this  is  equivalent  to  CD  quality  sound.  The  misanalogy  oceurs  because  quality  music 
recordings  require  higher  sampling  frequencies  than  quality  speech  recordings.  The  Human 
Factors  information  (Appendix  D)  clearly  indicates  that  sampling  frequencies  of  22  kHz  produce 
high  quality  speech  recordings  and  that  sampling  frequencies  above  22  kHz  do  not  add  to  the 
quality. 
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In  addition,  a  potential  conflict  between  the  Human  Factors  Expert  and  the  Computer 
Engineer  needs  to  be  resolved  to  achieve  the  most  efficient  system.  Tins  conflict  focuses  on  the 
type  of  speech  synthesis  that  will  be  used.  Due  to  speech  intelligibility  requirements,  the  Human 
Factors  Expert  is  likely  to  favor  using  digitized  synthesis.  The  Computer  Engineer,  however,  is 
likely  to  want  text-to-speech  due  to  its  reduced  data  storage  requirements.  The  two  competing 
viewpoints  can  best  be  satisfied  by  a  compromise.  The  compromise  involves  using  text-to-speech 
for  all  words  that  are  pronounced  according  to  common  pronunciation  rules.  But,  exceptions  can 
be  stored  digitally.  This  option  requires  only  1/3  of  the  data  storage  for  digitized  words  and 
maintains  high  levels  of  speech  intelligibility. 
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POTENTIAL  APPLICATIONS  FOR  AUTOMATE 


Many  potential  research  questions  could  be  addressed  using  this  paradigm.  Three  of  these 
questions  are  discussed  as  illustrations.  First,  design  teams  communicating  over  a  computer  can  be 
compared  with  those  communicating  face-to-face.  Since  computer-mediated  communication 
(CMC)  involves  a  narrower  bandwidth  than  face-to-face  (FTP)  communication  (Wellens,  1986; 
1989),  some  information  communicated  by  computer  may  be  lost  (e.g.,  nonverbals)  or  distorted. 
Communication  across  computers  may  actually  hinder  the  effectiveness  of  design  teams.  On  the 
other  hand,  CMC  may  diminish  pressures  for  team  members  to  conform  and  reduce  barriers  to 
social  interaction  resulting  in  more  equal  participation  than  FTP  (Kiesler,  Siegel,  &  McGuire, 

1984).  Thus,  it  would  be  interesting  to  use  the  AutoMate  paradigm  to  explore  whether  design 
teams  using  CMC  actually  discuss  more  unshared  information  than  FTF  design  teams. 

Second,  the  paradigm  can  be  used  to  study  how  teams  with  members  located  in  two 
different  locations  work  together.  If  multidisciplinary  design  teams  are  physically  dispersed, 
individuals  from  functionally  similar  domains  may  be  located  near  each  other  and  likely  to  form 
coalitions  or  subgroups.  These  coalitions  may  change  the  dynamics  of  the  communication  process 
because  teams  tend  to  be  more  competitive  than  individuals.  AutoMate  can  be  used  to  study  how 
coalitions  in  design  teams  might  influence  information  sharing. 

Third,  the  paradigm  can  be  used  to  study  how  design  tools  such  as  automated  databases  or 
design  rationale  databases  influence  team  decisions.  In  addition,  AutoMate  may  be  used  to  examine 
the  impact  computerized  design  demonstrations  or  rapid  design  prototyping  software  have  on  a 
tearn’s  development  of  a  shared  perspective.  For  example,  the  Computer  Aided  Systems  Human 
Engineering  (CASHE)  software  system  (see  Boff,  Monk,  Swierenga,  Brown,  &  Cody,  1991) 
includes  a  (1)  comprehensive  human  factors  engineering  database  and  (2)  human  perception  and 
performance  prototypers  which  could  be  used  to  amplify  the  human  factors  perspective  in  the 
Automate  task.  The  influence  of  these  types  of  computer  design  tools  on  information  sharing  and 
team  decision  making  would  also  be  interesting  to  examine. 
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Appendix  A 

Sound  Board  Options 


Voice  Player 
VOP645 

Orator 

OR987 

Sound  Creator 

SC555 

Sampling  Rate 

4  to  44.1  kHz 
programmable 

4  to  22  kHz 
programmable 

4  to  44.1  KHz 
programmable 

Operation  Temperature 

-550  to  1400  F 

-550  to  1850 F 

-550  to  1850F 

Text-to-Speech  Program 

Program  included  on 
board 

Program  included  on 
board 

Available  at  an  additional 
cost  of  $5.00  per  unit. 

Maximum  Current 

10mA 

10mA 

4mA 

Data  Compression  and 
Decompression 

None 

4:1 

4:1 

Price  per  unit 

$50.00 

$60.00 

$65.00 
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Appendix  B 


Design  Specifications  For  The  Automate  Audio  Display 

Cost 

•  Target  cost  is  $75  per  unit 

•  Cost  maximizing  profit  is  $60  or  less 

•  Cost  at  which  system  becomes  less  feasible  is  $100  or  more 


Features 

•  Messages  giving  brief  instructions  about  the  next  driving  maneuver  (e.g.,  lane  change,  turn, 
exit)  required. 

•  Messages  providing  driver  with  information  about  present  location  and  direction  heading 

Criteria 

•  High  quality  sound  is  preferable.  High  quality  sound  depends  on  the  rate  at  which  sound  is 
sampled.  The  higher  the  sampling  rate  the  better  the  sound  quality.  For  example.  Compact 
Disc  (CDs)  quality  sound  is  sampled  at  a  rate  of  44. 1  kHz. 

•  The  system  must  withstand  car  temperatures  that  vary  with  weather.  The  range  of  air 
temperatures  in  the  targeted  markets  varies  from  -200  F  to  1 100  F 

•  Data  storage  for  messages  must  be  under  70  Mb  or  the  cost  of  additional  memory  for  data 
storage  must  be  included  in  cost  estimates. 

•  Overall  cost  of  the  system 

Action  Decision  Items 

•  Which  sound  board  should  be  used?  _ 

•  What  type  of  speech  synthesis  will  be  used:  text-to-speech  or  digitized? 


•  What  is  the  estimated  total  cost  of  the  audio  display? 

Sound  Board  _ _ 

Speech  Synthesis  _ 

Additional  Memory  _ 

Total  Cost  _ 
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Appendix  C 

Speech  Synthesis  Options 


Two  basic  options  exist  for  generating  and  storing  messages  for  AutoMate’s  auditory 

display:  digitized  or  text-to-speech.  These  options  can  be  used  separately  or  in  combination. 

Digitized 

•  Messages  are  converted  into  a  format  that  a  computer  can  understand  and  stored  on  the  hard 
drive  of  the  computer. 

•  The  conversion  involves  sampling  sound  at  a  certain  frequency.  The  quality  of  the  sound 
will  depend  on  the  frequency  it  is  sampled  at.  Crisper  clearer  sound  is  produced  at  high 
frequency  rates.  Higher  sampling  rates,  however,  require  more  storage. 

•  Storage  requirements  are  dependent  on  the  sampling  rate  and  data  compression.  But,  can 
quickly  exceed  storage  capacity. 


Text-to-Speech 

•  Messages  are  generated  from  text  based  on  basic  rules  of  pronunciation.  A  set  of 
algorithms  is  used  to  break  down  a  written  word  into  its  basic  speech  components. 

•  Only  a  small  set  of  sounds  need  to  be  stored  to  produce  an  unlimited  vocabulary. 

•  Recent  advances  in  text-to-speech  synthesis  have  produced  high  quality  speech  for  most 
words  that  follow  the  basic  rules  of  pronunciation.  Exceptions  still  pose  a  problem.  About 
1/3  of  all  street  names  do  not  follow  typical  pronunciation  rules. 
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Appendix  D 

Human  Factors  Information 


Focus 

•  Usability 

Primary  Concerns 

•  Burden  on  Driver’s  Information  Processing  Demands 

Distraction— Users  should  not  be  distracted  from  their  primary  task  of  driving. 
Memory  Load— Users’  ability  to  remember  information  should  not  be  taxed. 

•  Intelligibility 

Identifiability— Users  should  be  able  to  correctly  identify  words  that  are  used  in 
messages. 

Quick  and  Easy  Recognition— Users  should  be  able  to  recognize  words  quickly 
without  having  to  decipher  them. 

Issues 

•  Digitized  messages  are  more  intelligible  when  sampled  at  a  higher  frequency. 

Under  optimum  conditions  (i.e.,  low  noise,  low  distractions,  etc.)  a  message  with  a 
frequency  range  of  200  to  6100  Hz  will  be  about  95  percent  intelligible.  Reducing 
this  rate  will  produce  a  decrease  in  intelligibility,  particularly  of  consonant  sounds 
such  as  "th"  which  are  composed  largely  of  higher  frequencies. 

A  good  rule  of  thumb  to  follow  is  that  sound  should  be  sampled  at  about  3  times  the 
highest  sound  frequency  that  you  are  interested  in.  The  intelligibility  of  speech 
increases  up  to  about  the  22  Idiz  sampling  frequency  and  then  levels  off.  This 
means  that  higher  sampling  frequencies  do  not  have  a  significant  impact  on 
intelligibility. 

•  The  intelligibility  of  digitized  and  text-to-speech  generated  messages  is  about  the  same  for 
most  words. 

For  exceptions,  digitized  messages  are  more  intelligible.  Exceptions  will  add  to  the 
operators  mental  workload  and  burden  processing  demands. 
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Appendix  E 

Computer  Engineer  Information 


Focus 

•  Performance  of  the  audio  display  given  computer  hardware  and  software  constraints 


Primary  Concerns 

•  Program  and  Data  Storage  Requirements 

Hard  disk  space  available  is  70MB 

Data  storage  depends  on  the  type  of  speech  synthesis,  the  rate  that  the  sound  is 
sampled  at,  and  the  amount  of  data  compression  available. 

•  Power  consumption  limitations 

Under  normal  operating  conditions  the  speech  processing  board  can  draw  no  more 
than  SOmA  of  current. 


Issues 


Information  stored  at  higher  sampling  frequencies  require  more  space. 

Information  stored  at  22  kHz  takes  half  the  space  that  information  stored  at  44. 1 
kHz  takes.  Compressed  data  takes  1/4  of  the  space  that  uncompressed  data  does. 
Below  is  a  table  estimating  the  storage  requirements 


Sampling 

Rate 

22  kHz 

44. 1  kHz 

All  street  names  digitized  and  stored 

With  Compression  (4:1) 

180  MB 

360  MB 

Without  Compression 

720  MB 

1.5  GB 

All  street  names  generated  text-to-speech 

With  Compression  (4: 1) 

10  MB 

20  MB 

Without  Compression 

40  MB 

80  MB 
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Appendix  F 

System/Safety  Engineer  Information 


Focus 

•  Quality  of  the  auditory  display  and  overall  fit  within  the  system 


Primary  Concerns 

•  Quality 

Reliability  of  performance-The  auditory  display  must  operate  consistently  without 
software  or  hardware  bugs. 

Must  meet  all  constraints  from  the  environment--The  display  must  operate  under 
extreme  weather  conditions  that  might  affect  automobiles. 

•  Fit 

The  sound  boards  must  fit  within  the  selected  computer  system 

Data  storage  requirements  beyond  70  MB  require  an  upgrade  to  the  hard  drive  of  the 
computer  used  for  the  navigation  system. 

Issues 

•  All  three  boards  have  been  tested  and  work  equally  well.  Quality  of  the  three  is  considered 
comparable. 

•  Overheating  of  the  sound  boards  could  be  problematic.  Due  to  the  greenhouse  effect  within 
an  automobile,  temperatures  usually  range  from  -350  to  1650  F 

•  All  three  boards  fit  within  the  overall  AutoMate  system 

•  The  cost  of  additional  data  storage  is  estimated  in  the  table  below. 


Cost  of  Additional  Data  Storage 


Cost 

70  MB 

200  MB 

360  MB 

720  MB 

1  GB 

2  GB 

Per  Unit 

$0 

$50 

$75 

$130 

$300 

$600 
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